原帖 ｜ 刘子奇 ｜ 2026-05-26 16:46 ｜ 👍3 ｜ 阅读约1
AI 现在能帮你快速写出一份“看起来很标准”的驱动：初始化、IO 配置、串口收发、甚至 RTOS 任务都齐了。
但你一上板：不进中断、串口丢包、偶发死机、功耗下不来。
这时候你会发现：AI 可以写代码，但不能替你对硬件现象负责。能跑只是入场券，能定位才是门票
嵌入式里最残酷的一句真话是：“能编译通过”不值钱，“能解释波形”才值钱。
AI 让你更快到达“能跑”，但真正拉开差距的是：出了问题你能不能把系统救回来。
01｜AI 让“写代码”变便宜了，但让“把系统做稳”更贵了
在嵌入式领域，AI 的确把很多事变快了：
现在大一建工程、写外设初始化、拼协议解析、做个串口屏、蓝牙、传感器采集、搭 RTOS 任务、写上位机脚本，甚至FreeRTOS 都系统不难，因为AI 能把模板拼得很快。
所以现在你会看到一个错觉：
大一也能做出像样的项目，大四的差距好像没以前大。 、
但找工作时差距不会消失，只会换地方出现：
展示能跑是入场券，解释为什么能跑、板子出了事，谁能把它救回来，才是录用门票。
02｜嵌入式最危险的学习方式：用 AI 用得太顺
嵌入式成长靠什么？ 靠“现象—怀疑—验证—定位—复盘”的循环。
而 AI 最容易让你跳过的，恰恰是这段。
不看数据手册，只会用 CubeMX 点配置，不会解释关键参数直接贴代码
只跑通正常路径，不量波形，不做不做异常/边界/长稳测试
不做异常分支，不写复现步骤，出问题全靠“再生成一版”，不会用工具验证（示波器/LA/抓包/日志）
你以为你在做项目，其实你在做“演示”。 太顺会消灭问题感； 没问题感的人，做不好嵌入式。
03｜AI 时代嵌入式真正的分水岭：4 件事
别只卷“我也能写驱动/写协议”。 你要卷的是：
判断力：这段配置有没有风险？ 时序/中断/并发/栈够不够？
验证力：你怎么证明它对？ 靠感觉还是靠测量？
排障力：不进中断/偶发死机/丢包/功耗高，你从哪一步下手？
收敛力：修完怎么防回归？ 怎么确保“只修了这一个问题”？
千万别把面试当背题，面试官通常在确认这四件事
AI 给答案很快，你的价值在“验证与负责”。
04｜基础还要不要学？ 要。 因为你得有资格怀疑 AI
AI 写寄存器配置、写 HAL 调用、写 RTOS 任务，都可能“看起来正确”。
嵌入式的问题是：看起来对 ≠ 物理世界对。
你学基础不是为了“从零手写所有代码”，而是为了：
看懂时钟树、总线、外设状态机
明白中断优先级、临界区、竞态条件
知道 DMA/Cache/内存屏障可能带来的诡异 bug
能读数据手册：时序、限制条件、注意事项、Errata
不学基础，你就只能赌 AI 没坑你。
05｜把 AI 当“嵌入式助教”用：5 条纪律（强制你不空心）
纪律 1：先画“怀疑清单”，再问 AI
遇到问题先写下3 个怀疑方向，例如：
时钟/复用/电源域没开对
中断没开/优先级冲突/ISR 做了阻塞
竞态条件：主循环与中断/多任务争资源
比如“不进中断”，先写 3 个怀疑点：
NVIC 配置/优先级/使能是否正确
外设中断源是否真正产生（状态位、触发条件）
入口函数名/向量表/编译优化导致的异常
然后再让 AI 帮你扩展和排序，让它帮你补漏、排序、给验证步骤。而不是直接让它给答案。
纪律 2：AI 给初始化代码，你必须做“对照验证”
至少做一项对照：
对照数据手册寄存器位（不是只看 HAL 文档）
对照 RM/DS：关键寄存器位确认无误
用逻辑分析仪/示波器验证时序或波形
读回寄存器打印（或用调试器观察）验证配置生效
STM32 的“对”不是 AI 说对，是参考手册说对。
纪律 3：任何“能跑”的 Demo，都必须补 3 类测试
边界：最大波特率/最大采样率/满缓冲/高频中断
异常：拔线、噪声、CRC 错、超时、重复包、乱序包
长稳：至少 2–8 小时跑起来，观察：错误计数、重启次数、栈水位
嵌入式的自信必须来自“长稳”，不是来自“演示”。
纪律 4：每次用 AI，都要留“证据链”
必须留这些材料（越像工程越值钱）：
复现步骤（可复制粘贴）
关键日志（带时间戳/计数器）
波形/抓包截图（标注你关注的点）
修改点（commit/diff）与验证结论
建议你项目仓库里固定有这些文件/目录：
/docs/：波形截图、时序标注、抓包
/test/：测试矩阵（你测了什么、怎么测）
ISSUE_LOG.md：bug 复现→根因→修复→回归
纪律 5：建立“AI 坑点库”（专治面试追问）
把你踩过的坑写下来，尤其是这些 STM32 高频雷区，例如：
ISR 里调用阻塞 API / printf/长时间处理
忽略 volatile / 内存对齐 / DMA 缓存一致性
超时重试策略导致任务饿死或风暴
忘了考虑栈大小、优先级反转、死锁
UART/DMA：IDLE 中断、半传输中断、缓冲区越界
FreeRTOS：优先级反转、栈溢出、临界区用错
时钟树：APB 分频导致定时器频率翻倍/不符合预期
低功耗：外设时钟没关、IO 漏电、唤醒源没清
能讲清楚“我踩过什么坑、怎么证明修好了”，比“我做过什么功能”更打动人。
06｜嵌入式自测题：你是真的会，还是只会“让它跑起来”？
交项目/投简历前，拿你的项目回答这几道题（建议写进 README）：
这段外设配置的关键寄存器位是哪几个？ 为什么这么配？
中断触发条件是什么？ 优先级怎么定？ 有没有抢占风险？
最可能的 3 个故障点是什么？ 你准备怎么定位？
你怎么证明时序满足？ 用什么工具量？ 量哪两个点？
异常输入来了系统怎么处理？ 会不会卡死/内存泄漏/重入？
长稳怎么测？ 你监控哪些指标（堆、栈水位、错误计数、重启次数）？
功耗下不来时，你的排查顺序是什么？ （外设时钟/IO 状态/唤醒源/睡眠模式）
你的系统时钟怎么配？ 为什么这样配？ 哪些频率是关键？
串口/通信如何防丢包？ 环形缓冲怎么做？ 溢出策略是什么？
DMA/双缓冲怎么保证数据一致？ 有没有竞态？ 怎么证明？
偶发死机怎么定位？ 你保留了哪些日志/断言/看门狗信息？
能回答这些，才算“你做的”，不然只是“你展示的”。
收尾｜AI 让“点灯”更容易，但“把板子做稳”更值钱
AI 会越来越强，你用它没问题，你也应该用它。
但嵌入式的本质不会变：物理世界会用现象打脸所有想当然。 波形不对就是不对，功耗高就是高，偶发死机就是会死。
所以别卷“生成速度”，去卷“判断+验证+排障+收敛”。
你要把项目做成面试官喜欢的样子：
有证据（波形/抓包/日志）
有过程（复现—定位—修复—回归）
有边界（什么时候不保证、瓶颈在哪）
有工程化（可读、可测、可维护）
AI 能帮你写代码，但“把系统做稳”才是你的核心竞争力。
奇问
你做 STM32 项目时，遇到过最难定位的“偶发问题”是什么？ 最后怎么收敛的？
你最想补的一项能力是：中断/串口DMA/RTOS/低功耗/硬件接口？ 为什么？
你希望我下一篇写哪类“STM32 求职项目模板”？ （比如：串口DMA环形缓冲、FreeRTOS日志系统、低功耗测量与优化）
附件：
- AI 把嵌入式门槛拉平了？ 真正的门槛是这 4 件事.pdf（392KB）
相关笔记